A primary feature of the development of computer systems and applications programs in recent years has been the increasing degree of interoperability between applications programs and, in particular, the degree to which applications programs can communicate and share data. It is now commonly expected that a given application program will be able to communicate and exchange data, and even calls for functional operations, with a number of other programs and a number of different approaches have been developed to provide such interoperability. One of the earliest approaches, for example, was the development of suites of applications programs, such as Lotus 1-2-3, that effectively comprised a single application program with an extensive array of functions, such as word processing, spreadsheets, databases and communications. A later approach was the development of operating systems, such as Microsoft Windows, that provided an integrated operating environment wherein applications programs that conformed to the environment are thereby able to exchange and integrate data between themselves.
A recurring problem in achieving integration between applications programs, however, is that it is often difficult or impossible, for many different practical reasons, such as economics or competitive efforts, to design programs to operate together directly. Although integrated operating environments offer some solutions for these problems, the problem remains because not all designers choose to fully conform with the operating environment. Even when applications programs do fully conform with an integrated operating environment, however, the results have been unsatisfactory because the degree and type of integration between applications programs is dictated by the operating environment, which may not provide the integration facilities required in a particular instance and which, in fact, may merely interpose additional interfaces and mismatches to be overcome. Further, the degree and types of integration provided by integrated operating environments are dictated by the operating environments, which are designed to provide only generalized integration facilities usable by a wide range of applications programs. As such, the data integration facilities of integrated operating environments often do not meet the needs of a particular application program or user and the user or application program is forced to adapt to the integrated operating environment, rather than the operating environment adapting to the user or application program.
This problem has been particularly acute with regard to interfacing between applications programs and databases, although it is a common feature in many systems that many of the applications programs executing therein will obtain the data that they work with from one or more common databases of different types. While the prior art has offered many approaches to the problem of database access by applications programs, these approaches have been generally unsatisfactory. Many, for example, depend upon the applications programs and the database programs being originally designed to work together, which is often not possible as the applications programs and databases are designed a different times and by different developers, or depend upon the facilities provided by an integrated operating environment, with the limitations and problems described above.
Still other solutions of the prior art have provided translation interfaces to be interposed between the applications programs and the database programs. These approaches have likewise been generally unsatisfactory, however, as they have required modifications to either the applications programs or the database programs and have thereby required that either applications programs or the database programs have knowledge of the data and command formats and functions of the other program. These approaches are further unsatisfactory in that the translations interfaces are generally specific to a given application or database program or set of programs and it is frequently difficult to adapt the translation interface to additional applications programs or database programs.
Still other approaches of the prior art include what are referred to as "rapid application development" (RAD) tools that provide programmatic interfaces to databases, such as Microsoft's Visual Basic or Borland's Delphi programs.
These approaches have been unsatisfactory, however, in many instances because, while the user is not required to be concerned with the detailed "back end" of database processing, that is, the actual creation of Structured Query Language (SQL) statements, the user is still required to have detailed knowledge of the database design, such as the tables, the table columns, the relationships between tables, and what groups of tables comprise a "data object". Also, and because the user is required to be knowledgeable of and involved in the details of data processing at each step of the processes that must be performed to achieve a desired object, it is very difficult for a user to create a system performing complex, multiple operations.
The present invention provides a solution to these and other problems of the prior art.